(1) Field of the Invention
The present invention relates to the field of computer science. More specifically, the present invention relates to a method for executing a procedure that requires input from a person other than an immediate user.
(2) Art Background
Modem business procedures often require different types of information to be routed to different people according to a pre-defined set of rules. Computers are ideal for automating these procedures, referred to as "workflows", for a number of reasons. First, communication between computers via the Internet and enterprise intranets have made information exchange efficient and inexpensive, even for geographically distributed enterprises. Second, many common business functions such as account management and inventory management are already performed by computers. By networking the computers that perform such business functions with computers used to automate workflows, it becomes possible to perform common business functions as part of a workflow execution. Finally, a workflow is similar to a computer program in that, once defined, a single copy of the workflow definition can be copied or downloaded for execution on multiple machines. By using the same workflow definition throughout an enterprise, compatibility and consistency between enterprise business procedures can be significantly
Execution of a workflow generally takes place in the background without any user interaction until communication with a role is required. Herein, the term "role" refers to one or more persons that must be notified in order to complete a particular operation within a workflow. For example, one common workflow role is an approver role. In order to execute an approval operation, an individual identified with the corresponding approver role must be notified to either approve or reject a request. That is, input must be received from the approver role. Another role that appears in many workflow processes is a requester role. Any individual that initiates a workflow process seeking a response from another individual or from an automated function fulfills a requestor role. Most workflow processes include at least one operation in which a requestor role is notified.
Executing a procedure that requires input from a role presents certain difficulties. One difficulty arises from the fact that a role cannot be expected to be present to respond when prompted for input. This is in contrast to a typical foreground processing application in which an immediate user is assumed, i.e., a user is assumed to be present and ready to supply input in response to a pop-up message, dialog box or other prompt.
Since a role cannot be expected to respond timely to a request for input, an issue arises as to what the requesting process should do while the request is pending. Of course, the process could block until the role responds to the request for input. However, it could be days or even weeks before the role responds. Since even blocked processes require system resources (e.g., stack, code and data space), this type of long-term process blocking can be wasteful.
Another problem, also arising from the fact that the role is not an immediate user, is the logistical problem of communicating the request for input to the role and receiving a response from the role. The process requesting input from a role is unlikely to be executing on the role's computer so that foreground prompting is usually not an option. Also, while networked computers can be programmed to provide a remote user-interface, there can be no assurance that the role's computer is networked to the computer executing the requesting process at the time the request for input is issued.
The difficulties that arise when a process must receive input from a role extend to background processing generally. Consequently, in the traditional background processing model, background processes are executed without user input beyond the initial input parameters. When processing activities are completed or errors are encountered, these events are recorded in an execution log. The execution log can be inspected from time to time to determine whether events of interest have occurred.
There are several disadvantages to the traditional background processing model. First, instead of being automatically notified when background processing events occur, users are effectively required to poll the execution log. Second, when the background process encounters an error, it may have to terminate since it has no mechanism for asking a user what corrective action should be taken. This can be wasteful, particularly when the error is encountered toward the end of a long process. Finally, the traditional approach to background processing limits the types of programs that can be executed in the background to those which require no user-input.
It would be desirable to provide a generalized method for detecting a request for user input in a procedure being executed in a background process, communicating the request to a user identified in the request, and then completing the procedure when the user supplies the requested input. Such a method could also be applied to support execution of a procedure that requires input from a role.